The present invention relates generally to collaborative applications, and more particularly to a collaboration model which can support the introduction of new object types into deployed network environments.
When a software system is to support an organization of software elements and humans working together, system designers must be concerned with certain community acts. The least complex of these acts is known as coordination, i.e., the act of harmonizing the performance of activities that may or may not have a common purpose such as the avoidance of resource conflicts. This harmonizing introduces the basic notions of concurrent systems, such as mutual exclusion, deadlock, and starvation. The act of working together toward a common purpose or end is known as cooperation, and typically involves coordination plus a synchronization of efforts. For example, the ordering of events among objects in order to achieve a certain goal requires an agreement among them to transmit signals indicating when certain events have taken place.
The most complex of the community acts is known as collaboration. This involves cooperation on a common effort requiring intelligence, defined here as the ability to acquire knowledge through experience, i.e., to learn, and to apply that knowledge. Arguably, both humans and software have the potential to exhibit intelligence.
A collaborative system is a software system that allows multiple agents to collaborate and communicate by sharing objects. An agent is a human or a software element possessing some degree of intelligence. Examples of software agents are software systems external to the collaborative system and workflow processes such as automated business processes within the collaborative system.
An object is a unit of software that often, but not always, corresponds to something in a real-world problem domain. People who extensively use direct-manipulation graphical user interfaces generally tend to blur the distinction between a software object, its graphical manifestation in a user interface, and its real-world referent. When viewed as software units, the shared objects referred to above with respect to a collaborative system may range in complexity from relatively simple passive objects that exhibit only reactive control (e.g, data objects that are stored in data bases), to active objects capable of proactive control and which can initiate interactions with other objects, to autonomous objects that exhibit intelligence by adapting their control mechanisms and behavior. Popular buzzwords for autonomous objects include xe2x80x9cagentxe2x80x9d and xe2x80x9cbusiness object.xe2x80x9d
A collaborative system provides object sharing, replication, and distribution; change detection and notification; change collection and reporting; change merging with conflict identification and resolution whenever possible; and propagation of changes and unresolved conflicts to agents. The key issue to be addressed in the design of a collaborative system is providing the collaborating agents with appropriate (not necessarily consistent) views of what is going on in the most efficient way for a particular collaborative situation. Before designing a collaborative system, designers must consider the range of collaborative situations the system is required to handle, and the constraints imposed by development and deployment environments.
Collaborative situations can be distinguished by sometimes-independent features. An example of one such situation is when each agent works with a local copy of an original object that is persistent on some central server. Here, there is no sharing among agents, but synchronization of the local copies with the persistent, original object will be required eventually. Another situation is when each agent works on objects that are independent of objects worked on by other agents. Here, the object sharing supports only inter-agent communication, e.g., to inform what each agent is doing. In yet another example, multiple agents work on the same objects or on objects that are interdependent. Here, object sharing supports not only inter-agent communication but also cooperation. Other situations are as follows: agents are working at different times; agents are working at the same time, but at locations that prohibit communication; agents are working at the same time and in locations that support real or near-real time communication; explicit rules exist for resolving conflicting changes so that resolution of conflicting changes (made by one or more agents) can be automated; only implicit rules exist for resolving conflicts so that conflict resolution cannot be automated; whether the agent population includes both humans and software elements; and the importance of protecting information and restricting access to it.
As an example of a collaborative situation, consider the following. Certain employees of a telecommunications service provider, each with a different role (set of responsibilities), collectively satisfy a customer service order, such as for two phone lines to a residence. Here, object sharing supports inter-agent communication and cooperation. Agents work independently (asynchronously) on some tasks and in concert (synchronously) on others. Some conflict resolution can be automated, while other conflict resolution requires human intervention. The agents include humans and software. Different agents have different access to information based on laws, regulations, agent role, and business considerations.
A number of considerations impact the design of the software to be developed and deployed. Such considerations include the number of developers (vendors) involved. The larger the number, the greater the need for an open architecture and a high degree of programming-language independence. Another consideration is the number of external systems with which the proposed system must interact. This consideration has the same consequences as the number of developers. Yet another consideration is the expected lifespan, which is influenced by economics and technology. To have a life that is both long and successful, a software system must have high evolvability. Further examples include whether it is reasonable for mobile agents to perform their work by using the collaborative system while physically connected to a central server, and the constraints imposed on the choice of client software for mobile and stationary agents. For example, are agents constrained to using only thin clients, like Web browsers.
Open architecture, programming-language independence, and evolvability are critical. Systems with open architectures provide well-defined interfaces that facilitate extension by (metaphorically) plugging in a new software component or swapping one software component for another. Such systems also promote the use of frameworks that allow systems to be configured by assembling and parameterizing components (modern techniques for configuring systems dynamically, i.e., at runtime).
Programming-language independence means that software elements will be able to work together independent of the programming language in which they were written. It allows different vendors to work in different programming languages. By definition, it means that developers can work and think closer to a conceptual level of the application problem and further away from the coding level of the programmed solution. Evolvability encompasses open architectures and programming-language independence and is discussed in more detail below.
For mobile agents, situations sometimes make it difficult or impossible to work while connected (wired or wireless) by mobile devices such as notebook computers. The application requires rapid response but the connections are slow or unreliable. The application is used in locations where physical connection is impossible. In such situations, the objects to be shared must be distributed, i.e., downloaded to the mobile devices.
In contrast, stationary agents usually access shared objects that reside on a central server. The current trend in industry is away from fat clients running on relatively powerful desktop computers and toward thin clients, such as Web browsers, running on relatively low-capability network computers or even lower-capability network appliances.
Thus, to have a life that is both long and successful, a software system must have high evolvability, which is defined as dynamic programmability in combination with dynamic maintainability. Dynamic means at runtime, while the system is operating.
Technology, regulations, and business organizations are continually changing, introducing new or modified products and services and new business practices. In some highly-competitive industries, such as telecommunications, many systems are considered mission-critical, even those that interact with customers over the Web. In order for companies to avoid the high and potentially disastrous costs of system obsolescence and down-time, the systems they deploy must be dynamically maintainable, i.e., they must have the capability to dynamically adapt, grow, and be updated or transitioned to new uses. Thus the individual operations that can be performed on a dynamically maintainable system are the same operations that can be performed on a system that is statically maintainable, except that they can be applied not only at design time but also at runtime. Some of these operations involve introducing new software components, including components that were not thought of when the system was originally deployed.
Open architectures facilitate introducing new software components, whether at design time or at runtime. However, runtime introduction also requires dynamic programmability. Dynamic programmability is the ability to perform operations on a binary executable runtime component that are traditionally performed on source code. Some of these operations include the following: to modify a component; to deliver to a site and to construct, new (to the site) implementations, such as class hierarchies in an object-oriented implementation; to register newly arrived or created components; to discover the protocols and services of components; and to negotiate a set of interactions with a component. By implication, dynamic programmability encompasses programming language independence.
As the state of the art moves closer to evolvable systems, the partitioning of responsibilities among roles such as developer, operator, administrator, maintainer, and end-user becomes more difficult. In this description, the term user refers ambiguously to all five roles.
As a result, collaborative systems can be quite complex. Building complex systems of quality, on-time, and within cost, is impossible without first describing the systems using models. Modeling raises the problem to an abstract level for resolution with minimal resources. A solution defined at an abstract level can then be translated to a concrete level as an implemented system.
As a result, a need exists for a model that can support the construction of collaborative systems that support a range of collaborative situations, and which can be developed by multiple vendors, have a long lifespan, and be deployed in a variety of environments, including wired and wireless networks.
Developers construct software systems with the goal of satisfying specific requirements, i.e., of providing certain capabilities and of meeting certain conditions, constraints, and expectations. Some kinds of requirements, such as expectations and certain performance requirements can be represented only in prose, which is inherently imprecise and ambiguous, e.g., the expectation xe2x80x9cThe user interface must be easy to use.xe2x80x9d Other kinds of requirements can be represented as formalized specifications, or concrete models, of the system to be built. These concrete models are precise and analytic to the degree of formalization of the notations, or abstract models, from which they are produced.
A collaboration model is an abstract model. In order to support construction of collaborative systems, a collaboration model must provide abstractions that support precise, analytic representations of collaborative application domains, as well as promote the specification of efficient designs in network environments for a range of collaborative situations. In addition, collaborative models must support the specification of designs with open architectures, dynamic programmability, and dynamic maintainability.
A collaboration model must be able to describe three categories of requirements: functional requirements, design requirements, and requirements for achieving evolvability. Note that while the purpose of these sections is to enumerate what a collaboration model must be capable of describing at design time, they also suggest what a collaborative system must be capable of performing at runtime.
Functional requirements concern what must be implemented in a collaborative system in order to solve the application problem. They describe the elements of an application problem domain, their structure and interrelationships, and their patterns of communication, behavior, and control. A collaboration model must have abstractions capable of describing the following:
objects of arbitrary complexity;
collaboration functionality (replication, distribution, cooperation, and synchronization of results) that can be applied at any arbitrary degree of granularity, from coarse-grained to extremely fine-grained, e.g., from the coarse grain of a complete diagram to the fine-grain of a single arrowhead on a directed line within a diagram;
replication of shared objects;
distribution of shared objects;
object sharing by multiple agents (humans, software elements, work processes);
communication patterns (inform, order events, asynchronous, synchronous);
work patterns (independently, in concert);
cooperation among work activities whether performed independently or in concert;
synchronization of work results to achieve system (enterprise) goals;
change detection and notification;
change collection and reporting;
change merging with conflict identification and resolution;
propagation of changes and unresolved conflicts synchronization that is automated and uses machine intelligence whenever possible; and
separation of factors that determine access to shared objects, such as role, security, and so forth.
Development requirements concern how a collaborative system will be developed in order to improve the lot of the developers. A collaboration model must have abstractions capable of describing the following:
participation of a shared object in any agent activity, such as a workflow process, independently of its participation in any other agent activity, or workflow process;
separate treatment of roles and security as factors affecting access to shared objects;
location transparency: agents and high-level system software elements are unaware of the physical location of shared objects, e.g., on central servers or distributed across clients;
uniform treatment of agents, whether human or software (facilitates replacing humans by software as technology advances and software systems become more powerful);
open architectures that promote the use of frameworks; and
programming-language independence.
These development requirements promote or are direct prerequisites for evolvability.
Evolvability requirements concern systems that can adapt, grow, and be updated or transitioned to new uses at runtime. A collaboration model must have abstractions capable of describing the following:
each of the operations that collectively make up dynamic programmability, discussed earlier; and
each of the capabilities that collectively provide dynamic maintainability, discussed earlier.
For collaborative systems, one critical issue relates to handling conflicts that arise from multiple concurrent access to resources. Principles of software design for concurrent solutions dictate that conflicts be considered at the highest level of abstraction possiblexe2x80x94at the conceptual level if possible. The most primitive mechanism for synchronizing concurrent access to shared objects is known as a xe2x80x9clock.xe2x80x9d Locks constrain low-level (relative to the conceptual level of the application problem) concurrency semantics to provide brute force conflict-prevention.
To overcome the deficiencies of lock mechanisms, some efforts have defined conflict-reduction mechanisms. Compared to locks, these mechanisms manifest higher-order concurrency semantics such as distinguishing commutative and non-commutative sequences of operations. For example, in an article entitled xe2x80x9cReduced-conflict objects,xe2x80x9d Journal of Object-Oriented Programming, vol. 10, no. 8 (January 1998), pp. 40-44, J. Almarode and R. Breti have defined reduced-conflict counters, bags, dictionaries, and so forth. However, because of their low-level of abstraction, conflict-prevention and conflict-reduction mechanisms are inadequate for complex collaborative systems. These systems need high-level conflict-detection and conflict-resolution mechanisms that can work in concert with sophisticated replication and distribution mechanisms. Conflict must be addressed at the system level.
In an article entitled xe2x80x9cSync: A Java Framework For Mobile Collaborative Applications,xe2x80x9d IEEE Computer, vol. 30, no. 6 (June 1997), pp. 59-66, J. Munson and P. Dewan provide a comparison of several collaborative systems which is summarized as follows. Lotus Notes provides replication and synchronization mechanisms with automatic, fine-grained change detection and synchronization, but supports only a relatively narrow range of object structures. Carnegie Mellon""s Coda provides coarse-grained replication at the file level (i.e., a file is required to represent each object), and then transports objects across the network as individual files. Such a system is necessarily cumbersome to program because it requires each replicated object to be independent, which objects generally are not. Xerox""s Bayou uses a tuple-store data model, which is inherently mismatched with modern object-oriented applications. In addition, several of theses systems (e.g., MIT""s Rover, Carnegie Mellon""s Coda, and Xerox""s Bayou) handle conflict detection on an update-by-update basis, which can result in inconsistencies unless all updates are mutually independent, which is unlikely in the general case.
Sync overcomes many of the weaknesses of these systems by supporting fine-grained change detection, and synchronization and replicated shared objects of arbitrarily complex structure. However, Sync suffers from a number of deficiencies such as the change notification mechanism is based on the model-view-controller (MVC) microarchitecture. Mechanisms based on MVC have the following disadvantages: they require considerable programming effort to use because MVC is so generic; they are hard to maintain over time because notification kinds are distinguished by textual labels; they have considerable runtime overhead because all notifications are sent to all dependents; they are inefficient when changes are fine-grained or indirect change propagation is involved. For example, a situation that illustrates all of these weaknesses is when an attribute of one object may be affected by changes in an attribute of another object. In this situation, one object must register interest with another object. When the attribute changes, the change notification must be propagated from the attribute (or operation affecting the attribute) to the object containing the attribute and then to all the dependent objects. A dependent object containing the attribute that is interested in the change must then invoke an operation that appropriately affects the interested attribute.
In addition, Sync does not explicitly support multiple views on and protected access to shared objects. Further, although Sync defines separate models for replication and change, the models are language-dependent (Java). Because the replication constructs are implemented directly as classes in a static language (Java), support for dynamic maintainability and dynamic programmability is severely weakened.
As noted previously the use of frameworks are to be promoted. A framework is a reusable implementation arranged to make it easier, quicker, and cheaper to develop software within a family of applications having similar features. At the macro (or system) level of granularity, a framework provides all the support needed to build, run, and maintain a system. A framework should free the developer from concerns about control (e.g., program structure, control flow, and calls to system-level APIs). The developer informs the framework which situations the developer""s code will handle and provides the code to handle them. When these situations occur at runtime, the framework invokes the programmer""s code. The programmer""s code does not call the framework.
There are two broad categories of frameworks. White-box frameworks use language-dependent features, in particular class inheritance and dynamic binding, which allow application developers to customize and extend a framework through subclassing or template parameterization. White-box frameworks require application developers to be somewhat intimate with the code, e.g., they must consider control issues. In contrast to white-box frameworks, black-box frameworks use language-independent mechanisms having component technology which uses object composition and delegation. This technology allows developers to customize and extend frameworks by inserting new components into a framework that has a plug-and-play interface. While providing superior advantage in use, the black-box frameworks are harder to develop because the plug-and-play interfaces (called hot-spots in the framework literature) must be designed to support the widest feasible range of possible uses.
As a result of the above, a need exists for a model for collaborative applications that can meet the above-noted requirements while overcoming the limitations of known arrangements.
It is therefore an object of the present invention to provide a collaboration model for collaborative applications which overcomes the above-described limitations in available programming while satisfying the enumerated design requirements.
It is another object of the present invention to provide a collaboration model which can support long-life collaborative applications in network environments such as the World Wide Web or wireless networks.
It is a further object of the present invention to provide a collaboration model suitable for evolutionary collaborative applications which can support introduction of new object types in deployed systems.
In accordance with these and other objects, the present invention provides a collaboration model for supporting construction of distributed systems and a range of collaborative situations having a type submodel arranged to isolate all other submodels from any external programming system by defining types as well as types of types, a change submodel responsive only to type submodel constructs and arranged to define a manner in which types and instances are allowed to change, and a programming language independent replication submodel arranged to define a manner in which multiple versions of objects are represented. A synchronization submodel is arranged to collect and report changes in isolation of potential changes, while a merge submodel is arranged to initiate collection of changes, identify conflicts, resolve conflicts, and propagate notification of whether changes were accepted, rejected, or a conflict could not be resolved. A distribution submodel is arranged to define a manner in which objects are physically transported across a system.
The collaboration model of the present invention provides several advantages. For example, change detection and notification hide programming details, represents events of interest as objects, allows selective notification, and promotes efficiency even for indirect, fine-grained changes. The present invention also provides separate treatment of factors that determine access to shared objects and location transparency of shared objects that not only makes programming easier, but also supports a range of deployment strategies. The present invention provides a more efficient distribution of shared objects when objects are related to other objects, and avoids the overhead, i.e., the inclusion of code which consumes memory and execution time, associated with replication functionality when situations do not call for replication. Situations that do call for replication include any situation involving distribution of shared objects or any situation involving complex collaboration with no distribution of (i.e., locally-maintained) shared objects. Still further, the present invention incurs the overhead associated with merge functionality only when situations call for merging. Situations that do call for merging include any situation that involves conflict detection and resolution. The present invention also avoids the overhead associated with distributed object functionality when situations do not call for distribution of shared objects. This benefit derives from the observation that multiple versions of a shared object may exist on a central server. In addition, open architectures are supported that not only promote the use of frameworks, but also explicitly treat potential variations (hot spots) and reuse contracts (framework technologies that have been insufficiently exploited). Finally, programming language independence and high evolvability are provided, along with a model architecture having a high degree of modularity achieved through decomposition into submodels that have strong internal cohesion and weak external coupling.